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Abstract 

Cooperative constraint solving is an area of constraint programming that 
studies the interaction between constraint solvers with the aim of discover- 
ing the interaction patterns that amplify the positive qualities of individual 
solvers. Automatisation and formalisation of such studies is an important 
issue of cooperative constraint solving. 

In this paper we present a constraint-based analysis of composite solvers 
that integrates reasoning about the individual solvers and the processed data. 
The idea is to approximate this reasoning by resolution of set constraints on 
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the finite sets representing the predicates that express all the necessary prop- 
erties. We illustrate application of our analysis to two important cooperation 
patterns: deterministic choice and loop. 

1 Introduction 

Cooperative constraint solving is an area of constraint programming that studies 
interaction between constraint solvers with the aim of discovering the interaction 
patterns that amplify the positive qualities of individual solvers. Papers [8, 2, 9, 13, 
6] describe some examples of successful cooperative constraint solving systems. 

At the present time, successful patterns of cooperation are detected with the 
sole help of intuition, feelings, experience, and experiments with software engi- 
neering tools supporting cooperative constraint solving such as [7, 12, 11, 10]. 
One cannot make such experiments systematic without a mathematical framework 
for analysis of cooperative constraint solving systems ("composite solvers"). 

An important practical application for such a framework is integration and de- 
velopment of domain-specific software. The expected applications for the analysis 
are detection of inconsistencies in the specifications of individual software pack- 
ages and construction of the specifications for the packages needed in order to meet 
the requirements on the over-all functionality. The COCONUT project is an exam- 
ple of such software development project in the domain of numerical optimization 
and constraint programming. 

The authors of [4] illustrate practical importance of analysis of composite 
solvers with examples from interval constraint programming. They point out two 
aspects of this analysis: (a) detection of good cooperation strategies subject to 
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expectations from the composite solver and the individual solvers in hand; (b) rea- 
soning about the properties of individual solvers subject to the expectations from 
the composite solver. In this paper we focus on the latter aspect. 

Certain properties of composite solvers are expressible in terms of the prop- 
erties of the processed data. One can study the properties of this sort using the 
frameworks of software verification, programming logics, model checking pro- 
gram analysis. In order to reason about the properties of individual solvers one 
needs a new kind of analysis. 

In this paper we present a constraint-based analysis of the composite solvers 
that integrates reasoning about the individual solvers and the processed data. The 
idea is to approximate this reasoning by resolution of set constraints on the fi- 
nite sets representing the predicates that express all the necessary properties. We 
illustrate application of our analysis to two important cooperation patterns: deter- 
ministic choice and loop. 

Before going further we give a quick motivational example. 

Example 1 (Motivation) Suppose that we, rather "engineers " than experts in 
global optimization, have in hand a library of numerical algorithms that includes 
the standard methods for local and global optimization, different tests, etc. and de- 
velop a software for minimization of quadratic functions (quadratic programming). 
Algorithm 1 specifies the composite solver that we have built with the intention to 
avoid the costly exhaustive search in the case of convex objective functions. 

Our logic is as follows: if the graph of the objective is like a tea-cup ( "con- 
vex"), then we use the steepest descent to go to its lowest point; otherwise we do 
the exhaustive search. Will this work? Well, sometimes: we have not thought of the 
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Algorithm 1 A naive composite solver for quadratic programming, 
if / is convex then 

solve x = arg min^o / by the method of steepest descent 
else 

solve x = arg min^o / by the exhaustive search 
end if 

objectives that are convex and unbounded from below in the orthant x > 0, e.g. 
f(xi, X2) = (xi — X2) 2 — x\. The method of steepest descent may fail to terminate 
in this case. 

How can we detect similar situations automatically? How do we change a 
composite solver in order that it work correctly? In this paper we propose a for- 
malism suitable for this kind of analisys. 

The paper is structured as follows. In Section 2 we introduce the basic notions 
of the paper and describe the operation of composite solvers. In Section 3 we 
describe a technique for reasoning about composite solvers in terms of constraints 
on finite sets. In this Section 4 we explain how to express certain properties of the 
composite solvers in terms of set constraints. Section 5 concludes the paper. 

2 Solvers, contexts, operation model 

In this section we introduce the basic notions of the paper and describe the opera- 
tion of composite solvers. 

A set of individual solvers that interact and exchange some data through a 
shared data store is called composite solver. We number the individual solvers by 
integers from 1 to n. The content of the data store, called context, is divided into 
control data and application specific data. The control data specify the set of the 
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individual solvers that "are called". In the constraint programming framework the 
application specific data are, usually, specifications in some declarative language. 
The set of all contexts is denoted C. 

The operation of the composite solver is divided into ticks. At the beginning 
of a tick every solver s checks the control data and either changes some part of the 
context if it is called, or does nothing otherwise. The initial context is provided by 
the user of the composite solver. Thus our composite solvers are either sequential 
or synchronous bulk parallel systems. 

A solver s determines a transformation F s : S — > S of the contexts at the 
beginning of the ticks into the contexts at the end of the ticks. The synchronous 
modifications of the data store must be coherent, that is, F s (c) = F s > (c) for any 
context c that contains the control data indicating that solvers s and s' are called. 

A context is feasible, if it is generated from the initial context by some sequence 
of the transformations F s 's where s's are some solvers. 

Now we proceed to the description of our constraint-based formalism. 

3 From composite solvers to finite sets 

In this section we describe a technique for reasoning about composite solvers in 
terms of constraints on finite sets. We axiomatize the operation model from Section 
2 in the first order logic and view the axioms as set constraints on the interpretation 
of the symbols involved therein. Since the exact solutions to these constraints may 
be (non-constructible explicitly) infinite sets, we solve our set constraints approxi- 
mately modulo a finite set of clusters of the contexts C. We assume that the reader 
is familiar with the generic concepts of constraint and constraint satisfaction. 
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The axioms in question are written in terms of a constant symbol cq denoting 
the initial context, a unary predicate symbol p denoting the set of feasible contexts 
and unary function symbols / s 's denoting the transformations F s . The axioms are 
plain and open (n is the number of individual solvers): 

p(co) (1) 
Vc p(c) A f s (c) = c p(c) s = l,...,n (2) 
Vc'Bc p(c') AcVct)^(c' = /i(c)V...Vc' = f n (c)) A p(c) (3) 

The axiom (1) states that the initial context is feasible. The n axioms (2) say 
that the transformations F s 's map feasible contexts onto themselves. The axiom 
(3) states that every feasible context except the initial one has a feasible pre-image 
under some transformation F s . 

The axioms (l)-(3) are nothing else than constraints on the interpretation c'o, p 
and f s 's, in the model-theoretic sense, of the symbols cq, p and / s 's. One can write 
down these constraints are as follows: 

fun (A) ,...,fun(/ n ) (4) 
p = {c'o} U img (A,p) U • • • U img (j n ,p^j (5) 

The domains of c'o, p and / s 's consist of the contexts S, of all the subsets of C and, 
respectively, of all the binary relations on S. The symbols = and U denote equality 
and union of subsets of S. The symbol fun denotes the constraint "is a function 
from S to C". The symbol img denotes the image of a subset of S under a binary 
relation on C. 
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Since many exact solutions to the constraints (4)-(5) involve infinite sets, we 
sacrifice precision for tractability and group the individual contexts from C into 
finitely many clusters called context properties, denoted C*. A binary relation on 
C* whose domain is C* is called abstract solver. A context property c* approx- 
imates a context c, iff c G c*. A set P* of context properties approximates a 
set P C C, iff P C UP*. An abstract solver R* approximates a binary relation 
R C C 2 , iff i? C Ui?*. 

Example 2 (Hull Consistency in sharpness analysis) Consider the Hull Consis- 
tency (HC) algorithm [1] from interval constraint programming. Given a set i of 
interval constraints, this algorithm computes a box b that bounds the set sol(i) 
of the solutions to i. Let the context specify the constraints i, the box b, and the 
necessary control data (of no interest at the moment). 

The well-known fact about the HC algorithm is that it bounds the set sol(i) 
sharply, i.e. b cannot be improved without losing a solution to i, if i has an acyclic 
constraint graph (see [5]). We can express this fact in terms of the context prop- 
erties "i has an acyclic constraint graph" (abbreviated tree) and "b = sol(z)" 
(abbreviated ok) by the abstract solver HC* = {(tree, ok) (C, C) (ok, ok)}. For 
example, (tree, ok) G HC* means that the HC algorithm bounds sol(z) sharply, 
if i has an acyclic constraint graph. 

Proposition 1 (Correctness) If c'o G C*, p C C* and abstract solvers f s 's ap- 
proximate some solution to the constraints (4)-(5), then they satisfy these same 
constraints with respect to the following definition of=, U, fun, img: 

f un(i?*) <^=^ R* is an abstract solver 
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img(i?*, P*) = the image of P* under R* 

P* U Q* = the standard union of subsets of 6* 
P* = Q* ■<=>■ the standard equality of subsets ofQ* 

In practice the constraints (4)-(5) are joined to (some of) the constraints 

f 1 = F*,...J n = F* (6) 

specifying the abstract solvers. We build these latter F*'s using two data bases that 
contain patterns of the individual solvers and the relation of logical equivalence on 
the set of properties of the processed data. 

A pattern of an individual solver is a collection of rules of the form "pre- 
condition — > post-condition" that have as common formal parameters the processed 
data and the called solvers. The pre- and post-condition are conjunctions of atomic 
formulas containing the formal parameters of the pattern. The formal parameters 
corresponding to the data not modified by the solver can be marked as "read-only". 

The fact that some solver is called is expressed by the unary predicate symbol 
do; the interpretation of other predicate symbols is arbitrary. The pre- and post- 
conditions in the pattern of a solver s are of the form do(s) A C and the symbol do 
does not occur in the conjunction C. Thus parallelism is not actually allowed. 

Let 7Ti, . . . , 7r n be the patterns of the individual solvers with instantiated for- 
mal parameters. The context properties are conjunctions do(s) A C, — where 
s = 1, . . . , n and C is a conjunction of the atomic formulas from m, . . . , 7r n , — 
that are not equivalent to the false conjunction. We assume that two equivalent 
conjunctions are the same object. 
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The image of a context property c* under the abstract solver F* corresponing 
to a pattern tt s is built as follows. Let c* = do(s') A C r0 A C rw such that every 
conjunct in C TW contains a value taken by some non read-only formal parameter of 
7r s and C r0 contains all the other conjuncts from c* except do(s'). 

Ifs ^ s'then img (F*, {c*}) = {c*}. Otherwise img (Ff, {c*}) = A {{C ro }}U 
{rhs(c^, 7r s )|c* is implied by c*} where each set of conjunctions is interpreted as 
the disjunction of its elements, e.g. {a, b} A {x, y} = {a A x, a A y, b A x, b A y}, 
and rhs(c*, 7r s ) denotes the set of the post-conditions following a pre-condition c\ 
in the pattern ir s . Finally, c\ "is implied by" c* iff c\ A c* is equivalent to c*. 

The next section illustrates our approach by several examples. 

4 Examples 

The examples in this section illustrate application of our approach to two important 
cooperation patterns: deterministic choice and loop. Our ultimate goal (out of the 
scope of this paper) is to couple the analysis with the language for specification 
of composite solvers in the framework of the COCONUT project. In order that 
the reader can feel our approach better, we provide in Appendix A the complete 
specification of the set constraints from Section 4.2. 

4.1 The naive solver from Section 1 

The patterns of the individual solvers from the example in Section 1 are as follows: 

cnvx?(ro(F); Si, S 2 ) = {do(l) A cnvx(F) do(Si), do(l) -> do(5 2 )} 
dscnt(ro(F), X; S) = {do(2) A stCnvx(F) -> do(S) A min(F, X), do(2) ->■ do(5)} 
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glblSrch(ro(F), X; S) = {do(3) do(S) A min(F, X)} 
done() = {do(4) do(4)} 

The symbols cnvx, stCnvx, min denote the properties "is convex", "is strictly 
convex", "is the global minimizer in the positive orthant". The only non-trivial 
equivalence is cnvx(F) A stCnvx(F) = stCnvx(F). The read-only parameters 
are marked ro. 

The instantiated patterns are cnvx?(/; 2, 3), dscnt(/, x; 4), glblSrch(/, x; 4), 
done(). The set of context properties is (we use the notation for disjunctions from 
Section 3): {do(l), do(2), do(3), do(4)} A {cnvx(/), stCnvx(/), min(/,x), 
true} A {min(/, x), true}. In practice these 24 context properties are numbered 
and the set constraints involve only their numbers. 

Of the specifications for F*, F£, F£, F£ generated by the procedure from 
Section 3, we provide the first one: 

img^*, {do(l) A cnvx(/)}) = {do(2) A cnvx(/)} 

imgCFf, {do(l) A stCnvx(/)}) = {do(2) A stCnvx(/)} 

img(i?, {do(l) A min(/, x) A cnvx(/)}) = {do(2) A min(/, x) A cnvx(/)} 

imgCFf, {do(l) A min(/, x) A stCnvx(/)}) = {do(2) A min(/, x) A stCnvx(/)} 

img(F 1 *, {do(l) A min(/, a;)}) = {do(2) A min(/, x) A cnvx(/), do(3) A min(/, a;)} 

imgOF*, {do(l)}) = {do(2) A cnvx(/), do(3)} 

and img(F*, {c*}) = {c*} for the other context properties c*. 

Solving the constraints (4)-(6) and c"o = do(l), we obtain the following ap- 
proximation for the set of feasible contexts: p = {do(l), do(2) A cnvx(/), do(3), 
do (4), do(4) A min(/, x)}. Since this p contains do(4), we are not sure that our 
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composite solver always finds the minimizer of f(x) subject to x > 0. 

The question "When does our composite finds the minimizer?" is translated 
into the constraints (4)-(6) and the constraints that say that we examine what hap- 
pens after the convexity test is called (do(l) "is implied by" cq) and forbid the 
uncertain situation after termination (do (4) p). Solving these constraints for the 
initial context cq, we obtain the following solutions: c'o = do(l) A stCnvx(/), 
c'o = do(l) A min(/, x) A stCnvx(/). This means that the objective has to be 
strictly convex in order that our solver can find its global minimizer. 

4.2 The Simplex method and Hull Consistency 

Consider a composite solver that makes cooperate the Simplex method from linear 

programming and the HC algorithm [1] (a similar composite solver is described 

e.g. in [2]). The context specifies some linear, interval and bound constraints, 

denoted £, i and, respectively b. The Simplex method updates b by bounding the 

solution set sol(£ U b) and calls the HC algorithm, which in its turn updates b by 

bounding the solution set sol(i U b) and calls the Simplex method, and so on until 

stabilization of b. The important quality of this strategy is that bounds the solution 

set sol(/ U i U b) more sharply than the HC algorithm. 
The patterns of the individual solvers are as follows: 

cplex(ro(L), B; S) = {do(l) -> do(S) A ok(i)} 

hc(ro(7), B; S) = {do(2) -> do(5), do(2) A tree(J) -> do(S) A ok(/)} 
same?(ro(S); Si,S 2 ) = {do(3) do(5i), do(3) do(5 2 )} 
done() = {do(4) -> do(4)} 
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The symbols ok, tree denote the properties "has the solution set that we can 
bound sharply", "has an acyclic constraint graph". All the equivalences are trivial. 

The instantiated patterns are cplex(£, b; 2), hc(i, b; 3), same?(6; 1, 4), doneQ. 
There are 32 context properties built as follows: {do(l), do(2), do(3), do(4)} A 
{ok(£), ok(i), tree(i), true} A {ok(i), tree(i), true} A {tree(i), true}. 

The specifications for the abstract solvers F*, F£, F£, F£ generated by the 
procedure from Section 3 are provided in Appendix A. 

Solving the constraints (4)-(6) and c'o = do(l), we obtain the following ap- 
proximation for the set of feasible contexts: p = {do(l),do(l) A ok(^),do(2) A 
ok(f), do(3) A ok(f), do(4) A ok(£)}. Since this p contains only do(4) A ok(f), the 
solution set of the linear constraints is always bounded sharply after termination of 
the composite solver. 

We can figure out when the composite solver bounds the solution set sol(£ U 
iUb) sharply, solving the constraints (4)-(6) and the constraints that say that we 
examine what happens after the Simplex method is called (do(l) "is implied by" 
c'o) and that the solution set is bounded sharply after termination (cqo € p, do (4) A 
ok(i) A ok(^) "is implied by" Coo). These constraints have 6 solutions. The first 
two assign do(4) A ok(^) A ok(i) to Cqo and either do(l) A ok(i), or do(l) A 
ok(i) A ok(£) to c'o. The other four assign do(4) A ok(^) A tree(i) A ok(i) to 
Coo and one of the 4 context properties that "imply" do(l) A tree(i) to c'o- This 
means that, the composite solver bounds the solution set sol(^ U i U b) sharply, if 
the interval constraints i have an acyclic constraint graph. 
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5 Conclusion 



We have presented a formalism for automatic analysis of composite solvers. This 
formalism provides a structure for expressing properties of the data store (context 
properties), a structure for specifying the behaviour of solvers (abstract solvers), 
a method for approximation of composite solvers by set constraints that can be 
efficiently solved by conventional set constraint solvers like [3, 14]. The ultimate 
goal (out of the scope of this paper) is to couple our analysis with the language for 
specification of composite solvers in the framework of the COCONUT project. 

Acknowledgements We thank Lucas Bordeaux from lTnstitut de Recherche en 
Informatique de Nantes for the comments on quantified constraints. 

Disclaimer No solver has been damaged during the preparation of this document. 
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A Specification of the example from Section 4.2 

The constraints from the sharpness example are provided in Fig. 1 in the LogiCalc 
language [14]. We recall its syntax/semantics. The LogiCalc language allows the 
user to specify constraints on integer numbers, tuples and finite sets. Tuples of 
sets, sets of tuples, sets of sets, etc. are allowed. The constraints are specified in 
terms of set inclusion subset, membership in, equality =, and inequality <=. 
The left and right hand sides of the constraints are expressions built from variables, 
arithmetic and set operations, and specifications of finite set. 

Finite sets are specified by either enumeration of the elements, or by their com- 
mon property. For example, 

x subset { 2 , 3 , 5 , 7 } ; 

y = { i * j | i in x; j in x; i + 1 <= j } ; 
y = { 6, 10, 15 } 

specify the set y = {i ■ j\i e x,j e x,i < j} = {6, 10, 15} and the set x — {2, 3, 5} of 
their prime factors. Notice implicit existential quantification of the variables i and j that 
do not occur outside the specification of y. Notice that the equation y = {i ■ j \ . . .} is, in 
fact, a constraint on x and y. 
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% Notation for the data properties: % 

treel = 0; okL = 1; okl = 2; treelokL = 3; 

oklokL = 4; true = 5; treelokl = 6; treelokLokl = 7; 
Cdata = { treel, okL, okl, treelokL, 

oklokL, true, treelokl, treelokLokl }; 



% cplex 
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F2star = 
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{ ((12, 


z2) , 


(12, z2)) 


i2 in 


{ 1, 3, 4 }, 


z2 


in 


Cdata 


}; 


% same? 


o. 
o 
















F3star = 


{ ((3, z3), (13, 


z3) ) 


I z3 in Cdata, 


i3 


in { 1, 


4 } }; 


% done % 


















F4star = 


{ ((4, z4), (4, 


z4) ) 


| z4 in Cdata 


}; 









% constraints (4) — (5): % 

imgl = { ell | (cl, ell) in Flstar; cl in p }; 
img2 = { c22 | (c2, c22) in F2star; c2 in p }; 
img3 = { c33 | (c3, c33) in F3star; c3 in p }; 
img4 = { c44 | (c4, c44) in F4star; c4 in p }; 
p = { cO } \/ imgl \/ img2 \/ img3 \/ img4; 

Figure 1: Specification of the sharpness example in the LogiCalc language; {} 
denotes the empty set, \/ denotes set union, Flstar specifies the abstract CPLEX, 
F2star specifies the abstract arc consistency, cO denotes the initial context that we 
search for, imgl, img2 denote the images of the set of feasible contexts under the 
abstract CPLEX and arc consistency. 
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